The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In computer networks such as the Internet, packets of data are sent from a source to a destination via a network of elements including links (communication paths such as telephone or optical lines) and nodes (for example, routers directing the packet along one or more of a plurality of links connected to it) according to one of various routing protocols.
The current Internet Protocol (IP) version, version 4 (IPv4) is gradually being succeeded by version 6 (IPv6). In either case IP provides the Internet layer mechanism for transporting upper layer information between devices. For example, as is well known to the skilled reader, in TCP/IP (Transport Control Protocol over Internet Protocol) a TCP connection is made between source and destination devices at the transport layer and then data exchanged between the devices is sent in one or more packets at the Internet (network) layer.
FIG. 1 is a schematic diagram showing a typical IPv4 packet. In particular FIG. 1 shows a common case where the packet length exceeds the maximum packet length (maximum transmission unit (MTU)) in which case the whole packet must be split up into individual data packets or fragments termed here fragment packets for the purposes of clarity. In particular each fragment packet 1 and 2, reference numerals 110, 112 include respective headers 114 and 116. Each header includes source and destination IP addresses 100, 102, information about the upper layer protocol 104 and an options header which contains additional information 106, amongst other potential fields. In addition each fragment packet carries the data payload 108 including the upper layer (for example TCP) data, split up into appropriately sized fragments. Each packet is sent from the source node to the destination node via intermediate nodes according to one of the available routing protocols. The packets may not all pass via the same route but are reassembled by the upper layer protocols at the destination device.
In the case of IPv6, the packet architecture is somewhat different as described in the document “RFC 2460—Internet Protocol, V6 (IPv6) specification” of Dearing et al which is available at the time of writing on the file “RFC 2460.html” in the directory “httip://rfc.net” the entirety of which is incorporated by reference as if fully disclosed herein. IPv6 is a protocol that is well known to the skilled reader such that detailed description is not required here and so a summary of the relevant points only is provided with reference to FIG. 2 which shows a packet divided into fragment packets according to IPv6.
IPv6 introduces various changes over IPv4 including increasing the IP address size, simplification of header format and improved support for header extensions and options. The general format of an IPv6 header 200 can be seen in FIG. 2. The header 200 includes a version field 202 which indicates IPv6, a traffic class field 204 allowing differentiated service for different classes of packet, a flow label field 206 allowing identification of flows requiring specific handling (for example real-time service), a payload length field 208 indicating the length of the packet or fragment packet following the header, a next header field 210 identifying the type of header immediately following the IPv6 header 200 and a hop limit field 212 which is decremented each time a node forwards the packet, the packet being discarded if the hop limit is decremented to zero. The packet further includes a source address field 214 and a destination address field 216.
The value carried in the next header field 210 may simply indicate the protocol where the next header is the TCP header, followed by the TCP data. Alternatively the next header value may indicate a subsequent extension header for which various possibilities are identified in rfc 2460. For example the next header may indicate a “hop-by-hop options” header which carries information or options that must be examined and processed by every node forwarding the packet. A further possibility is a “destination options” header indicating that the options therein must be processed by the node corresponding to the destination address in the IPv6 header. A further possibility is a routing header which can list additional destinations to the destination address which must process central options.
A further extension header comprises a fragment header. This is used by an IPv6 source to send a packet larger than the MTU. The fragment header includes an offset value allowing the position of the fragment packet within the complete packet to be identified.
The manner in which IPv6 fragment packet are structured can be further understood with reference to FIG. 3 which is a schematic diagram showing multiple headers in that scenario, where fields common with those shown in FIG. 2 and requiring no further description are commonly referenced. The packet includes an IPv6 header 318 which identifies IPv6 as the version in field 302 and a next header field 304 identifies a hop-by-hop header as a next header. The hop-by-hop extension header 320 identifies in its next header field 306 a fragment header as the next header and carries a length value 308 and “hop-by-hop options” in the field 310. The fragment header 322 includes, in its next header field 312, identification of the TCP protocol for the next header and an offset value 314 indicating how far through the whole packet the fragment packet appears. The fragment content itself is provided at 316 and includes, for the first fragment, the TCP header and data and, for subsequent fragments, additional TCP data. It will be noted that each fragment packet includes the hop-by-hop header as the hop-by-hop options must be processed at each forwarding node in the path.
In operation, when upper layer protocol data such as TCP data is sent from the source device it is reassembled into an IPv6 packet or multiple IPv6 fragment packets which are then sent towards the destination. The various packets may take different paths through intermediate nodes to be assembled at the destination device where upper layer protocols reassemble the fragments in the correct order, obtain any lost fragments and so forth. However intermediate nodes or routers only examine the IPv6 header together with, if specified, any hop-by-hop options before forwarding the packet or fragment packet to the destination address. However in some cases, for example that of access list filtering, the intermediate router needs to determine the packet protocol for example TCP or another protocol in order to determine whether the router can handle the packet. In access control list (ACL) implementations of this kind, if the packet is filtered out or cannot be assessed then a simple “deny” command may be applied as a result of which the packet will be dropped.
In the case of IPv6, therefore, a problem arises as in many cases the protocol is not contained in the IPv6 header, for example if the next header is a hop-by-hop header or if the packet is a fragment packet. In order to obtain information, therefore, packet reassembly may be required at the intermediate router according to an upper layer protocol. Even in this case, however, the information may not be available for example if an unknown header is present. It should be noted that the range of next header values is increasing in particular for example with mobile IP implementations such that reassembly by non-configured intermediate nodes may become less desirable in view of the risk of packet loss.